Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-161.txt

Text File | 1994-12-08 | 45.0 KB | 1,283 lines | [TEXT/R*ch]

C.S.M.P. Digest             Wed, 05 Aug 92       Volume 1 : Issue 161

Today's Topics:

    SCSI sample routine (Courtesy of Thomas R. Shaw, OTIC, Inc.)
    Does error 25 ("dsMemFullErr") come from QuickDraw?
    MoreMasters and INITs
    Programming secrets 2nd ed.
    Dialog Question...
    Dragging text...
    Apple's Resource compression



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (David Dantowitz)
Subject: SCSI sample routine (Courtesy of Thomas R. Shaw, OTIC, Inc.)
Date: 3 Jul 92 03:14:03 GMT
Organization: UCLA Computer Science Department


Here's a sample low-level SCSI routine that was posted to AppleLink by
Thomas R. Shaw of OTIC, Inc.  Please honor his copyright notice below.

- ---- cut here -----
/* file: scsisample.h

(c)1990-1992 OTIC, Inc., Thomas R. Shaw, POB 510073, Melbourne Beach, FL 32951,
INTERNET: [e-mail] AppleLink: D0430
You may reuse and incorporate this into other packages with the proviso that
credit is given and if used in a commercial package a copy of the package is
provided to the author.

*/

#define scsiReadXfer 1
#define scsiWriteXfer -1
#define scsiNoXfer 0

OSErr
DoSCSIOutput(
    short TargetSCSIID,
    short scsiCmdSize,
    void * scsiCmd,
    SCSIInstr *scsiInst,
    short RdWrNone,
    long TimeOut);



- ---- cut here -----
/* file: scsisample.c

(c)1990-1992 OTIC, Inc., Thomas R. Shaw, POB 510073, Melbourne Beach, FL 32951,
INTERNET: [e-mail] AppleLink: D0430
You may reuse and incorporate this into other packages with the proviso that
credit is given and if used in a commercial package a copy of the package is
provided to the author.

*/


//Here's a routine that we use. HoldBufferMemory is used to lock memory for VM.

#include <stdio.h>
#include <scsi.h>
#include <stdlib.h>

#include "scsi sample.h"

#define HoldBufferMemory(a, b) HoldMemory(a, b)
#define ReleaseBufferMemory(a, b) UnholdMemory(a, b)


#define kSCSIStatusMask 0x1f

#define kGood 0x00
#define kCheckCondition 0x02
#define kBusy 0x08
#define kReservationConflict 0x18

#define kSCSIRetryValue 5

#define bLogicalUnitLSB 5

#define kCommandComplete 0x00
#define kExtendedMessage 0x01
#define kSaveDataPointer 0x02
#define kRestorePointers 0x03
#define kDisconnect 0x04
#define kMessageReject 0x07
#define kLinkedCommandComplete 0x0a
#define kLinkedCommandCompleteWithFlags 0x0b


enum
{
eSCSIReservationConflict=0xf000,
eSCSIBusy,
eDisconnect,
eMessageReject,
eReplyTOErr
};


#define DoSCSISenseUnit(TargetSCSIID, LogicalUnit) FindError(TargetSCSIID)

//#pragma segment SCSISupport
//CorPascal OSErr

OSErr
DoSCSIOutput(
  short TargetSCSIID,
  short scsiCmdSize,
  void * scsiCmd,
  SCSIInstr *scsiInst,
  short RdWrNone,
  long TimeOut)
{
short  ReturnedSCSIStat;
short  ReturnedSCSIMessage;
short  NumTries = 0;
short  stat;
OSErr  err;
OSErr  err1;
short  i;
short  message;

  HoldBufferMemory(scsiCmd, scsiCmdSize);
  HoldBufferMemory(scsiInst, 100);

  while (NumTries++ < kSCSIRetryValue)
    {
       err = SCSIGet();

       if (err == noErr)
         {
         err = SCSISelect(TargetSCSIID);
         if (err == noErr)
           {
           err = SCSICmd((Ptr)(scsiCmd), scsiCmdSize);
           if (err == noErr)
             {
             stat = SCSIStat();

             switch (RdWrNone)
               {
               case scsiReadXfer:
                 err = SCSIRead((Ptr)scsiInst);
                 break;

               case scsiWriteXfer:
                 err = SCSIWrite((Ptr)scsiInst);
                 break;

               default:
                 break;
               }
             }

           err1 = SCSIComplete(&ReturnedSCSIStat, &ReturnedSCSIMessage, TimeOut);

           if (err == noErr)
             {
             if (err1 == noErr)
               {
               switch (ReturnedSCSIStat & kSCSIStatusMask)
                 {
                 case kGood:
                   err = noErr;
                   break;

//                 case kConditionMetGood:
//                   err = noErr;
//                   break;

//                 case kIntermediateGood:
//                   err = noErr;
//                   break;

//                 case kIntermediateMetGood:
//                   err = noErr;
//                   break;

                 case kReservationConflict:
                   err = eSCSIReservationConflict;
                   break;

                 case kBusy:
                   err = eSCSIBusy;
                   break;

                 case kCheckCondition:
                   switch (ReturnedSCSIMessage)
                     {

                     case kCommandComplete:
                     case kLinkedCommandCompleteWithFlags:
                     case kLinkedCommandComplete:
                       err = DoSCSISenseUnit(TargetSCSIID,
                         scsiCmd->LUN_Res >> bLogicalUnitLSB);
                       break;

                     case kExtendedMessage:
                       if (SCSIMsgIn(&message) == noErr)
                         {
                         for (i = 0; i < message; i++)
                           {
                           if (SCSIMsgIn(&message) != noErr)
                             break;
                           }
                         }
                       break;

                     case kSaveDataPointer:
                       break;

                     case kRestorePointers:
                       break;

                     case kDisconnect:
                       err = eDisconnect;

                     case kMessageReject:
                       err = eMessageReject;

                     default:
                       if (ReturnedSCSIMessage >= 0x80)
                         {
                           err = noErr;
                         }
                       else
                         err = DoSCSISenseUnit(TargetSCSIID,
                           scsiCmd->LUN_Res >> bLogicalUnitLSB);
                       break;
                     }
                   break;
                 }
               }
             else
               err = err1;
             }
           break;
           }
         }
       }

     if (NumTries >= kSCSIRetryValue)
       err = eReplyTOErr;

     ReleaseBufferMemory(scsiCmd, scsiCmdSize);
     ReleaseBufferMemory(scsiInst, 100);

     return (err);
}

//For simple Xfers you don't need the scsi-2 extra processing.

//- Tom

//Author: D0430
- --
David Dantowitz
[e-mail]

Singing Barbershop when I'm not doing parallel simulation

---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: Does error 25 ("dsMemFullErr") come from QuickDraw?
Organization: Kalamazoo College
Date: Tue, 23 Jun 1992 19:05:01 GMT

I think I remember reading somewhere that QuickDraw will return 25, not
- -108 ("memFullErr"), if it runs out of memory.  I'm getting a lot of
these in GetFontInfo calls, and I was wondering if anyone could verify
that for me.  If it's not QuickDraw, what might it be?  Any other
little tidbits will be appreciated too.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Never piss off a computer.

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 2 Jul 92 18:03:55 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Jamie R. McCarthy) wrote:
>
> I think I remember reading somewhere that QuickDraw will return 25, not
> -108 ("memFullErr"), if it runs out of memory.  I'm getting a lot of
> these in GetFontInfo calls, and I was wondering if anyone could verify
> that for me.  If it's not QuickDraw, what might it be?  Any other
> little tidbits will be appreciated too.
> --
>  Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
>  Never piss off a computer.

  The older QuickDraw routines will generate a system error 25 if it can't
get enough memory to complete an operation.  This is the infamous "Jackson"
symbol you'll see in MacsBug.  Newer QuickDraw routines are better behaved
an will return errors.

- -- Dean Yu
   Blue Meanie, Negative Ethnic Role Model, etc.
   Apple Computer, Inc.

---------------------------

From: [e-mail] (Jeremy Roussak)
Subject: MoreMasters and INITs
Date: 28 Jun 92 09:18:05 GMT
Organization: Computer Science Dept, QMW, University of London

A simple question: if an INIT (sorry, system extension)
allocates a moderately large number of handles in the system
heap at startup time, and retains them for the duration of the
session, should it call MoreMasters for the system heap?

Jeremy

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 29 Jun 92 17:36:59 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jeremy
Roussak) writes:
>
> A simple question: if an INIT (sorry, system extension)
> allocates a moderately large number of handles in the system
> heap at startup time, and retains them for the duration of the
> session, should it call MoreMasters for the system heap?

It doesn't matter much. The best time to call MoreMasters is just after the heap
has been created. An application can call MoreMasters pretty close to this time,
but not so with INITs. By the time INITs get called, the heap already has a ton
of blocks allocated. The bottom line is that it won't hurt much if you don't,
but you don't gain much benefit if you do. I guess that if I were in your
position, I'd go ahead and call MoreMasters.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 30 Jun 92 00:51:36 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Keith Rollin)
wrote:
>
> of blocks allocated. The bottom line is that it won't hurt much if you don't,
> but you don't gain much benefit if you do. I guess that if I were in your
> position, I'd go ahead and call MoreMasters.

I agree with your analysis, but not with the conclusion.  Since you
probably won't gain anything by calling MoreMasters on the System Heap, I
would say that the less you mess around with the System Heap the better.

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 30 Jun 92 18:15:34 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Larry
Rosenstein) writes:
>
> In article <[e-mail]>, [e-mail] (Keith Rollin)
> wrote:
> >
> > of blocks allocated. The bottom line is that it won't hurt much if you
don't,
> > but you don't gain much benefit if you do. I guess that if I were in your
> > position, I'd go ahead and call MoreMasters.
>
> I agree with your analysis, but not with the conclusion.  Since you
> probably won't gain anything by calling MoreMasters on the System Heap, I
> would say that the less you mess around with the System Heap the better.

Uh, oh. The guy who wrote MMInit going head to head with the guy who wrote
MacApp's memory management routines. Will the world survive?

I still stick by my guns, Larry. The master pointer blocks are going to be
allocated anyway, regardless of whether the original poster calls MoreMasters or
not. My feeling is that it's better for him to call MoreMasters so that the
master pointer blocks are at least together in memory.

"Better" here is a very relative word. The difference is so small as to make
almost no difference at all. The system heap is already a cluttered mess of
relocatable and non-relocatable (and sometimes orphaned -- thank you, N&C)
blocks that it's hard to make it any worse.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 2 Jul 92 18:01:18 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Jeremy Roussak) wrote:
>
> A simple question: if an INIT (sorry, system extension)
> allocates a moderately large number of handles in the system
> heap at startup time, and retains them for the duration of the
> session, should it call MoreMasters for the system heap?
>
> Jeremy

  Just as a bit of info, NewHandle will create another master pointer block
if there is no space for another master pointer in existing blocks.  The
reason
you would want to call MoreMasters is because master pointer blocks are
non-
relocatable blocks in the heap, so allocating these blocks early in your
program
helps to reduce heap fragmentation.
  Having said that, if you're really going to use that many handles, then
yes,
you should call MoreMasters for the system heap, keeping in mind that each
call
to MoreMasters gives you space for 64 master pointers.

- -- Dean Yu
   Blue Meanie, Negative Ethnic Role Model, etc.
   Apple Computer, Inc.

---------------------------

From: [e-mail] (Stephen Marshall)
Subject: Programming secrets 2nd ed.
Organization: Victoria University of Wellington
Date: Mon, 29 Jun 1992 01:12:16 GMT

Hi, I understand that the second edition of Macintosh Programming Secrets
is out, does anyone have the details - Author, ISBN etc. and a potted
summary?

Thanks for any help
Stephen


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 29 Jun 92 17:41:31 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Stephen Marshall) writes:
>
> Hi, I understand that the second edition of Macintosh Programming Secrets
> is out, does anyone have the details - Author, ISBN etc. and a potted
> summary?

I'm the co-author (along with Scott Knaster). The ISBN is 0-201-58134-5.

I'm a bit biased, so I'll let others tell you if they think it's any good. From
the private mail I've received, however, it seems that most people like it
(whew!).

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Thad Humphries)
Date: 30 Jun 92 03:17:51 GMT


  KR> From: [e-mail] (Keith Rollin) Newsgroups:
...
  KR> I'm the co-author (along with Scott Knaster). The ISBN is
  KR> 0-201-58134-5.
  KR>
  KR> I'm a bit biased, so I'll let others tell you if they think it's any
  KR> good. From the private mail I've received, however, it seems that most
  KR> people like it (whew!).

It is an *excellent* book, proof reading errors and all.  In fact, you should
have my $20 for the disk by now.

+++++++++++++++++++++++++++

From: [e-mail] (Jerry Sy)
Date: 30 Jun 92 22:16:24 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)


In a previous article, [e-mail] (Thad Humphries) says:

>  KR> From: [e-mail] (Keith Rollin) Newsgroups:
>...
>  KR> I'm the co-author (along with Scott Knaster). The ISBN is
>  KR> 0-201-58134-5.
>  KR>
>  KR> I'm a bit biased, so I'll let others tell you if they think it's any
>  KR> good. From the private mail I've received, however, it seems that most
>  KR> people like it (whew!).
>
could keith rollin or scott knaster explain what the meaning of the cover
of their new book ? like who are the people in the picture, up stairs
company, I love IBM, Inside Mac vol XXXVIII, etc.

jerry

+++++++++++++++++++++++++++

From: [e-mail] (Jerry Lobdill)
Date: Tue, 30 Jun 1992 07:00:29 -0500

'Twas a dark and stormy night (6/29/92) when Keith Rollin rose and said to
All...

  KR> From: [e-mail] (Keith Rollin) Newsgroups:
  KR> comp.sys.mac.programmer Organization: Taligent
  KR>
  KR> In article <[e-mail]>,
  KR> [e-mail] (Stephen Marshall) writes:
  KR>
  > Hi, I understand that the second edition of Macintosh Programming
  > Secrets is out, does anyone have the details - Author, ISBN etc. and a
  > potted summary?
  KR> I'm the co-author (along with Scott Knaster). The ISBN is
  KR> 0-201-58134-5.
  KR>
  KR> I'm a bit biased, so I'll let others tell you if they think it's any
  KR> good. From the private mail I've received, however, it seems that most
  KR> people like it (whew!). -- Keith Rollin Phantom Programmer Taligent,
  KR> Inc.
 ******************
I have the 1st edition and think it is excellent. Can you say anything about
what's new in the 2nd edition?

Thanks,
*********************

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 Jul 92 18:01:03 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jerry
Sy) writes:
>
>
> In a previous article, [e-mail] (Thad
Humphries) says:
>
> >  KR> From: [e-mail] (Keith Rollin) Newsgroups:
> >...
> >  KR> I'm the co-author (along with Scott Knaster). The ISBN is
> >  KR> 0-201-58134-5.
> >  KR>
> >  KR> I'm a bit biased, so I'll let others tell you if they think it's any
> >  KR> good. From the private mail I've received, however, it seems that most
> >  KR> people like it (whew!).
> >
> could keith rollin or scott knaster explain what the meaning of the cover
> of their new book ? like who are the people in the picture, up stairs
> company, I love IBM, Inside Mac vol XXXVIII, etc.

Hey, bud. See the coupon in the back of the book? You're supposed to pony $20
for privileged information like that!   :-)

OK, here's the deal (by the way, the cover of the book was the topic of a trivia
scavenger hunt at this year's WorldWide Developer's Conference).

On the spine is an inverted picture of the dogcow. That's the Anti-dogcow, which
seemed the appropriate logo for two ex-DTS workers (the dogcow is the mascot of
Mac DTS).

Scott is the one sitting down with the Jolt Cola. I'm the one standing next to
him with the Pink Floyd album ("Pink." Get it?). The guy in the red sweater is
Andy Hertzfeld, and the guy shooting the spitball at me is Bill Atkinson. Not
only do these two people have a lot to do with the genesis of the Mac, but they
also work with Scott at General Magic. The kid on the skateboard is Jess
Knaster, Scott's son, and the babe whose picture is on the desk is Laura Palmer
from Twin Peaks (an old girlfriend of mine said "Yeah, and I can see her twin
peaks, too"). Finally, the guy on the wall with the darts in him is Bjarne
Stroustrap, the progenitor of C++.

On the wall on the left is a poster of Flood, the second most recent They Might
Be Giants album. You might guess that that poster is there because both Scott
and I are Giants fans (see the cap on Scott's head, the bat in the lower-right
corner, and the Giants-A's World Series brochure at the bottom), but it's also
the album that Scott listened to while writing the prose of the book.

Van Dyke apartments is where Scott's mother lives.

Between Andy and the Flood poster is the AppleShare icon, positioned to look
like it's Andy's real hand and arm. On top of the computer Andy is hold is
coffee and donuts, also from Twin Peaks. On the screen of the monitor Andy is
holding is the original Enterprise, not that luxury yacht they show on TNG.

On the bookshelf next to Andy are: Macintosh ROM Source Listing binder, How To
Write Macintosh Software, Inside Mac Volume XXXVIII, Cooking With HyperTalk (a
book by Scott and Dan Winkler), Oddyssey (by John Sculley), and the Baseball
Encyclopedia.

On the floor in front of the bookshelf is a box with Pinball Trader (a pinball
newsletter put out by a friend of ours), the Star Trek Concordance, a Mad
Magazine (Scott has collected _every_ issue), and the World Series brochure.

In front of the box (in the dust created by Jess's skateboard) are some
Macintosh UI elements. There's a menu, a couple of alert icons, a window, and a
pattern palette.

Jess is on a skateboard for no really good reason. On the skateboard with him is
the surfer dude from the cover of Inside Mac VI (he's the icon for the
SurfWriter application alluded to in examples inside IM VI). They've just hit
Clarus the dogcow, which is why he'd flying up in the air. (I actually have a
different theory on why Clarus is in the middle of the air. When I worked in
DTS, the term we used for developers who had just done something really stupid
is "grazing off the cliff." I'm of the feeling that Clarus just grazed off the
edge of the desk.)

On the side of the desk above Jess is a "I Heart IBM (from now on)" bumper
sticker, alluding to the Apple/IBM alliance. The "Upstairs Company" logo next to
it is Barbara Knaster's consulting company (Barbara is Scott's wife).

On the right hand side, next to the desk is the Macintosh garbage can. Next to
that is a sleeping Giants bat.

Bill Atkinson is sitting at a desk with a computer with the General Magic Logo
on the screen. Above that screen, on the wall, is a picture of the critter in
the Alien movies. Above Bill's head on the back wall is the cover from Selling
The Dream (Guy Kawasaki's second book) and a flyer for Tony and Alba's pizza
(GREAT pizza!). Just in front of Bill is the Apple logo.

Behind me is a pink door ("Pink." Get it?) with a Tall Gent on it and the
Taligent logo beneath it.

Finally, on Scott's chest is a Happy Face button with a red arrow in blood
pointing to the 11:30 position. This is from The Watchmen, a "comic" book of
dire foreboding. Going back even further, the Happy Face with arrow on it is the
symbol of a group of physicists (I think that's right) who post their opinion on
how close the world is to nuclear armageddon. The closer the arrow gets to
midnight, the closer they think we are to blowing ourselves off the face of the
planet.

Well, I think that's about it. If I've missed anything, just point it out.

By the way, the cover was created and drawn by Angelo Torres of Mad Magazine. He
also did the cover of How To Write Macintosh Software, 3rd edition.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 Jul 92 19:39:07 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Jerry Lobdill) writes:
>
> 'Twas a dark and stormy night (6/29/92) when Keith Rollin rose and said to
> All...
>
>   KR> From: [e-mail] (Keith Rollin) Newsgroups:
>   KR> comp.sys.mac.programmer Organization: Taligent
>   KR>
>   KR> In article <[e-mail]>,
>   KR> [e-mail] (Stephen Marshall) writes:
>   KR>
>   > Hi, I understand that the second edition of Macintosh Programming
>   > Secrets is out, does anyone have the details - Author, ISBN etc. and a
>   > potted summary?
>   KR> I'm the co-author (along with Scott Knaster). The ISBN is
>   KR> 0-201-58134-5.
>   KR>
>   KR> I'm a bit biased, so I'll let others tell you if they think it's any
>   KR> good. From the private mail I've received, however, it seems that most
>   KR> people like it (whew!). -- Keith Rollin Phantom Programmer Taligent,
>   KR> Inc.
>  ******************
>
> I have the 1st edition and think it is excellent. Can you say anything about
> what's new in the 2nd edition?
>
> *********************

The second edition is almost entirely new.

As you may recall, the first edition was split into two parts. The first part
was a historical background and philosophy section. The second part was a
technical section (but, alas, lacking in source code samples). The two sections
were divided by a cartoon showing how the event manager worked.

In the new edition, the book is still split up into two parts. The first section
is mostly the same, updated to take out anachronisms (like references to the
possibilities of multi-tasking and 32-bit cleanliness) and add current
information (like System 7.0 stuff).

The cartoon has been replaced by famous Apple About boxes. The first is the
unexpurgated MultiFinder 1.0 about box (the official release version had all the
good parts bleeped; we've put them back in for the book). The second is the text
from the circus parade from one of the preliminary 7.0 release CD's.

The second section is where all the new information are.

Chapter 3 shows the application skeleton used for all the samples in the book.
Rather than duplicate the same code that handles initialization, windows, and
menus in each chapter, we show it just once. All the subsequent chapters tweak
the skeleton a little and then get on with the interesting stuff.

Chapter 4 is on dialogs. It shows how to handle modal, modeless, and
movable-modal dialogs. The sample for the modal dialog is based on an idea in
the first book, where command-key equivalents are assigned to all the dialogs
items. The modeless dialog shows a sample "Find" dialog that uses the 7.0
popupmenu control. The movable-modal dialog shows how to do a progress indicator
like the Finder's.

Chapter 5 talks about QuickDraw. It starts off a lot like the QuickDraw chapter
of the first edition, but then delves a little more into current color issues.
The second half of the chapter implements an idea put forth in the first
edition, where offscreen buffers are used to save the contents of background
windows when a dialog is displayed, and then used to restore the contents of
those windows when the dialog is dismissed.

Chapter 6 deals more with QuickDraw and shows how to do mouse tracking. The
sample program reads in a MacPaint picture. The user can then use the mouse to
etch out a rectangular selection that does the "marching ants" animation. The
selection can then be clicked on and dragged around. Offscreen buffers are used
for this, too.

Chapter 7 gets into window management. We show how to implement Tile Windows and
Stack Windows menu items, and show how to do a Window menu that keeps track of
all the open windows. The algorithms for tiling and stacking work across
multiple monitors.

Chapter 8 delves into the File Manager. A simple program is shown that allows
the user to select a file (using Standard File), and target directory (again,
using Standard File) and then copies the file to the destination in small
chunks. The reader is encouraged to integrate the copy routine with the progress
indicator shown in Chapter 4.

Chapter 9 develops different kinds of standalone code. The first sample is a
simple INIT that beeps at startup. Then a more realistic INIT is given that
causes a command-key sequence to zoom the frontmost window (I actually use this
INIT in my everyday work). Next, we show how to implement an LDEF that draws
icons and grays out disabled items. Finally, we give the source code to a
windoid WDEF (the kind of window usually associated with floating windows). Note
that we don't actually show how to do floating windows (bummer).

Chapter 10 is a collection of little routines that aren't large enough to
qualify for chapters of their own. We show how THINK programmers can do spinning
cursors based on MPW's 'acur' resources. We even show how such animation can be
done an interrupt time (even though I personally don't approve of the practice).
We show how applications can check for Command-Period without calling
WaitNextEvent, and how to implement a password-entry dialog box with the little
bullet characters. We also show how to hide the menubar.

In summary, chapters 1 and 2 are a lot like the first edition. Chapters 4, 5,
and 7 are partially based on information and ideas in the first edition. The
remaining chapters (3, 6, 8, 9, and 10) are totally new. If you get the second
edition, keep the first edition handy, because there's a lot of material we
threw away (like a lot of stuff dealing with printing and the Finder desktop
database).

All of the chapters include complete source code (in THINK C) to all of the
interesting stuff we talk about. Two people have complained about our not
including and resource dumps, but all of the resources we use are
straightforward enough that we didn't want to fill up pages and pages with
blocks of data (Like icons. I used to hate that about the old MacTutor -- I hope
the new MacTutor is better). Besides, we used ResEdit exclusively, and there
were no .r files.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Stephen Marshall)
Organization: Victoria University of Wellington, New Zealand
Date: Thu, 2 Jul 1992 22:56:01 GMT

Well, thanks to Keith and the others who replyed, I have decided to go
ahead and buy it, although I must say I would have been much happier if
the code was Pascal rather than C, as I'll probably have to go out and
buy Think C 5 as well 8-)

Thanks to all who replied
Stephen

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 3 Jul 92 11:58:30 GMT
Organization: Kalamazoo College

[e-mail] (Keith Rollin) writes:
> [ On the cover of his new book... ]
>On the wall on the left is a poster of Flood, the second most recent They Might
>Be Giants album. You might guess that that poster is there because both Scott
>and I are Giants fans (see the cap on Scott's head, the bat in the lower-right
>corner, and the Giants-A's World Series brochure at the bottom), but it's also
>the album that Scott listened to while writing the prose of the book.

This is quite appropriate, since TBMG used a Mac Plus as a sequencer on
their first album.  If you've heard that album, you know that the Mac
was playing 90% of their music for them...   :-)

They may still be using Macs, I don't know; I gleaned that info-tidbit
from one of those trendy college magazines a few years back.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "Whenever I open the manuals for OOP, I have the strangest desire to find
  the nearest pillow and fall asleep."   - David Denboer

---------------------------

From: [e-mail] (James Edwards)
Subject: Dialog Question...
Organization: George Mason University, Fairfax, Va.
Date: Thu, 2 Jul 1992 17:55:46 GMT

I have been pulling my hair out over this, but I'm sure that I'm just
not seeing how to make this code work.  I have a dialog box, model, that
has a number of picture items on it, and accompanying check boxes.  What
I want to do, is have the picture change to a different pict resource
when I click on the check boxes.  I know how to get and set the check
box data, but how do I tell the picture item to switch from , for
example, PICT resource 800 to 801?  I know that the picture item is
stored as two bytes in the item list, but I can't figure out how to
manipulae that value.  I know that for some items, you can cast them as
a ControlHandle, and then use the COntrol Manager to make the changes,
but I don't know how to do a picture.  Any helkp anyone has would be
appreciated.

I had thought about makeing the pictures user items, but that seemed
overly tacky if I could do it some simple way.  Thanks,

Jimi


+++++++++++++++++++++++++++

From: [e-mail]
Date: 2 Jul 92 20:16:11 GMT
Organization: AECL RESEARCH

I had to do much that same thing heres how I did it in C

    pict = GetPicture(128);
    GetDItem(theDialog,theItem,&itemType,&item,&box);
    SetDItem(theDialog,theItem,itemType,(Handle) pict,&box);
    InvalRect(&box);

Note I assume that the two pictures are the same size (If they aren't you'll
must adjust the item display rectangle 'box').

[e-mail]
Mike Dobrohoczki
Chalk River Laboratories
Atomic Energy Canada Ltd.

---------------------------

From: [e-mail] (Peter Wayner)
Subject: Dragging text...
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 3 Jul 1992 17:44:32 GMT


I need to be able to drag some text around the screen,
but whenever I try to set SetPen(patXor), it doesn't
seem to work. Is the DrawChar routine resetting the
pen? Or am I missing something really trivial or stupid?

- -Peter
- --
Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
EMail:[e-mail]    Office: 607-255-9202 or 255-1008
Home: 116 Oak Ave, Ithaca, NY 14850  Phone: [phone]


+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 4 Jul 92 00:30:25 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.cornell.edu> [e-mail] (Peter Wayner) writes:

   I need to be able to drag some text around the screen,
   but whenever I try to set SetPen(patXor), it doesn't

You probably mean PenMode...

   seem to work. Is the DrawChar routine resetting the
   pen? Or am I missing something really trivial or stupid?

Yes. Text is drawn with the more called TextMode. You
should use srcOr for fast text drawing, or srcXor for
your dragging needs (doing it offscreen would look better,
of course)

NOTE: "srcXxx" NOT "patXxx" for TextMode, or you will break
on the SE, Plus and Classic (and possibly future macs)

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

---------------------------

From: [e-mail] (michael j darweesh)
Subject: Apple's Resource compression
Date: 30 Jun 92 15:57:47 GMT
Organization: UB

Does anyone know anything about Apple's Resource compression
scheme?

More specifically, I have written a programmers' tool to compress
resources and have a nice programmers' interface to decompress at
run-time. Of course, it would be nice if I could offer, as a feature,
the ability to compress resources into Apple's scheme for even more
transparent decompression (even if my compression generally has a
better ratio and decompresses at about the same speed-VERY quickly).

I'm guessing that the format is a big secret and/or
proprietary/patented/otherwise not available, but perhaps I'm wrong...

I've been wrong before.

- -Mike Darweesh

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Tue, 30 Jun 1992 20:04:49 GMT

.edu> [e-mail] (michael j darweesh) writes:

   I'm guessing that the format is a big secret and/or
   proprietary/patented/otherwise not available, but perhaps I'm wrong...

Yes, that's true. Someone reverse-engineered it, though, and
sells apps to compress other apps.

HOWEVER: the format is subject to change without further notice,
and will PROBABLY DO SO !

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 1 Jul 1992 00:15:58 GMT

[e-mail] (michael j darweesh) writes:
>
>Does anyone know anything about Apple's Resource compression
>scheme?

Yeah.  The guys that wrote it do.  Last I heard, they were planning on
providing an interface at some future date, when everything was all
solidified and everything.  Of course, that was A YEAR AND A HALF AGO!

Everyone's given up hope, I think, and Apple's probably thinking it'll
be a pleasant surprise when they publish the interface sometime in 1996.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "Whenever I open the manuals for OOP, I have the strangest desire to find
  the nearest pillow and fall asleep."   - David Denboer

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 1 Jul 92 04:52:54 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Jon W{tte) writes:

>HOWEVER: the format is subject to change without further notice,
>and will PROBABLY DO SO !

Hmmm... the format changing doesn't break thing automagically, since the
system would have to provide that fabled Backwards Compatibility we programmers
all hate. What's possible is that a newer version wouldn't do a very good
job of backwards compatibility, and minor mistakes in the reverse engineering
which don't show up now could do so. Well, that's what they said about PICT,
anyway...

#include <personal_opinion.h>
- --
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett

+++++++++++++++++++++++++++

From: [e-mail] (michael j darweesh)
Date: 1 Jul 92 06:38:34 GMT
Organization: UB


ok, I've read the responses. It appears that the best thing to do would be
to release my version as I was planning and offer an upgrade if the time
and proper information ever make it my way.

Right now, I have a nifty application which compresses resources in my
format. It does especially well on color PICTs and larger textual resources.
It compresses slowly, but you only need to do this once in a while.

The decompression is tremendously quicker and easy to implement. Basically,
you just call a resource as you would a function with a resource handle
as an argument. I've written a small set of instructions and everything.
It's really even easier than it sounds. No icky source code to mess with.
No $199 per copy fees like some other similar products either.

Oh, and BTW, my compression has been better than Apple's in almost every
instance tested.

So, if I released this as shareware, would anyone use it? Bug fixes and
feature requests would probably be handled quite promptly in most cases.

Let me know what you think...
Personal E-mail or post here...

- -Mike Darweesh
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 1 Jul 92 15:41:21 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Mark Lanett) writes:
> [e-mail] (Jon W{tte) writes:
>
> >HOWEVER: the format is subject to change without further notice,
> >and will PROBABLY DO SO !
>
> Hmmm... the format changing doesn't break thing automagically, since the
> system would have to provide that fabled Backwards Compatibility we programmers
> all hate. What's possible is that a newer version wouldn't do a very good
> job of backwards compatibility, and minor mistakes in the reverse engineering
> which don't show up now could do so. Well, that's what they said about PICT,
> anyway...

Why do they have to be backwards compatable?

If I recall recorrectly, they only use compressed resources in
the system software.  This means that when they change the
compression scheme, they need to update the resources to use
the new scheme, not the old.  Not a very hard thing to do if
you are updating the system software.  Why bother to be
backwards compatable with a format you no longer use?

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Lorne J. Kingsley)
Date: 1 Jul 92 20:23:12 GMT
Organization: General Electric R&D

In article <[e-mail]>, [e-mail]
(michael j darweesh) wrote:
>
> Does anyone know anything about Apple's Resource compression
> scheme?
>
> More specifically, I have written a programmers' tool to compress
> resources and have a nice programmers' interface to decompress at
> run-time. Of course, it would be nice if I could offer, as a feature,
> the ability to compress resources into Apple's scheme for even more
> transparent decompression (even if my compression generally has a
> better ratio and decompresses at about the same speed-VERY quickly).
>
> I'm guessing that the format is a big secret and/or
> proprietary/patented/otherwise not available, but perhaps I'm wrong...
>
> I've been wrong before.
>
> -Mike Darweesh

Maybe I'm missing something here, but isn't this *exactly* what Alysis'
More Disk Space does? I seem to recall they offered to license the
compression schemes do developers for a small fee.

They also mentioned they used the same scheme that Apple used in System 7.

You might want to contact them before going whole hog on this - it might
have already been done.

- - Lorne

**************************************************
Lorne J. Kingsley         General Electric Company
standard disclaimer: my ramblings in no way
represent those of the General Electric Company
Internet: [e-mail]
CI$: 75166,2550
America Online: LorneK1
**************************************************

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 1 Jul 92 16:25:34 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>.edu> [e-mail] (michael j darweesh) writes:

>   I'm guessing that the format is a big secret and/or
>   proprietary/patented/otherwise not available, but perhaps I'm wrong...

>Yes, that's true. Someone reverse-engineered it, though, and
>sells apps to compress other apps.

>HOWEVER: the format is subject to change without further notice,
>and will PROBABLY DO SO !



No matter what Apple does to change the compression scheme its still
going to have to be backward compatible right? If I'm running system 7.X
or 8.0 and I open an old system file, Its still going to have to know how
to uncompress the compressed resources. They might add new and better
de/compressors but I think that the current format is pretty much carved in
stone at this point.


Matt







- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 2 Jul 92 10:35:31 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ge.com.> [e-mail] (Lorne J. Kingsley) writes:

   Maybe I'm missing something here, but isn't this *exactly* what Alysis'
   More Disk Space does? I seem to recall they offered to license the
   compression schemes do developers for a small fee.

However, I'm leary of MDS, since my disk fixing programs,
startup disks etc do not have MDS installed. And it does
not seem as solid as AutoDoubler, and I was not pleased
with AutoDoubler instead.

I'm getting a larger drive - maybe I'm just too cautios.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 2 Jul 92 10:39:04 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Matt Mora) writes:

   >HOWEVER: the format is subject to change without further notice,
   >and will PROBABLY DO SO !

   No matter what Apple does to change the compression scheme its still
   going to have to be backward compatible right? If I'm running system 7.X
   or 8.0 and I open an old system file, Its still going to have to know how
   to uncompress the compressed resources. They might add new and better
   de/compressors but I think that the current format is pretty much carved in
   stone at this point.


Not at all. Compression is only found in system files. SO, special
case for opening an old system file, and use that compression then,
else use the new compression.

There is no way that a non-apple file can "legally" have compressed
resources.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

---------------------------

End of C.S.M.P. Digest
**********************